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REMARKS 

Claims 7-1 1 are pending in the present application. Claim 7 is currently amended to 
more clearly define "backing up database files" as requiring "completely rewriting said database 
data file to a backup system." While applicant submits that this limitation is intrinsic in the term 
"backing up" such amendment should preclude overbroad interpretation of the term "backing 
up" by the Examiner to include performing a restore operation or redoing failed transactions, for 
example. 

Rejections Under 35 U.S.C. $103 

Claims 7-1 1 are rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent 
No. 5,499,367 to Bamford et al. (hereinafter "Bamford") in view of U.S. Patent No. 5,970,488 to 
Crowe et al. (hereinafter "Crowe"). Claim 7, as amended, which is representative in part of the 
other rejected claims recites: 

7. In a computer system having a plurality of nodes, each node having access 
to a shared common database and also having local storage, a method of 
performing a backup operation to completely rewrite said shared common 
database comprising: 

providing a local archived redo log in local storage for said node, said 
node including information regarding data in said shared common database; 

selecting at least one node of said plurality of nodes to perform said 
backup operation to completely rewrite said information regarding data in said 
shared common database included in said node; 

obtaining information regarding a directory location of said local redo 
log for said at least one node; 

setting said local redo log to be read/write accessible by said selected at 
least one node; and 

bacliing up database data files, control files and arciiived redo logs in 
said shared common database by accessing data in said shared common 
database and also in said local archived redo log to provide backup data and 
completely rewriting said database data files to a backup system, (emphasis 
added.) 

The Examiner maintains an overly-broadly interpretation of the claim term "backing up 
data" and continues to incorrectly assert that Bamford teaches "backing up data in said shared 
common database by accessing data in said shared common database." Applicant respectfiiUy 
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submits that Bamford discloses storing data in a shared common database and use of a 
distributed log to redo failed transactions to the shared common database . Bamford does not 
teach anything about backing up data in the shared common database by completely rewriting 
the shared common database. 

To more clearly show that the claims require a "backing up of data" as opposed to re- 
doing failed transactions, for example, claim 7 is currently amended to recite, among other 
things, "backing up of database data files. . . by. . . completely rewriting said database data files to 
a backup system." 

Applicant maintains that a prior-art system described by Bamford uses "a back-up copy 
of the contents of the database. The backup copy is a duplicate copy of the original database that 
is made periodically" (Col. 2, lines 23 - 26). "A recovery in a database system means recovery 
of the database itself. That is, restoring the database to a state that is known to be consistent and 
reasonably recent." (Col. 2, lines 20 - 23). Since the backup copy may not reflect transactions 
that occurred after the time the backup was made and before the failure of the database system 
(col. 2, lines 28 - 30), a redo log is used to sequentially write short records containing 
information sufficient to redo the changes . (Col. 2, lines 33 - 41). Thus, in the background 
portion of Bamford, a prior-art redo log is first described for use with a back-up copy of the 
contents of an original database to provide a persistent backup/restore function with no local 
logs. In Fig. 2 of Bamford, a prior-art system is described with reference to local logs 208, 209 
which did not include information in a shared common database. 

Later in the background portion of Bamford, with reference to Fig. 1, the redo log is 
described for use in redoing a failed transfer of data between a cache buffer 107, 108, 109, 110, 
111 or 112 and an [original] database 106 (col. 2, line 66 - col. 3, line 7) as opposed to a 
backup/restore function, with no mention of any back-up copy of the contents of the database. 

Even if it is assimied for the sake of argument that Bamford's redo log may be used for 
maintaining data persistence in both restore operations and in redoing a failed transaction 
between cache buffers and a shared common database, Bamford does not disclose backing up 
data in the shared common database at all, let alone backing up data in said sliared common 
database by accessing data in said sliared common database and also in said local archived 
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redo log to provide backup data and completely rewriting said database data files to a 
backup system as particularly claimed. Further, Bamford surely does not disclose or suggest 
"backing up database data files, control files and archived redo logs in said shared common 
database. . ." as Applicant particularly discloses and claims in amended claim 7. 

The Examiner also incorrectly asserted that Bamford teaches "obtaining information 
regarding a directory location of said redo log for said at least one node" as particularly 
claimed. The Examiner cited "column 10, lines 23 - 59, and column 14, lines 3-9, wherein a 
log is located for the client)." Here Bamford describes log formats (col. 10, line 21 - col. 11, 
line 3), and a log manager (col. 14, line 4). Applicant respectfully submits that Bamford does 
not teach or suggest anything about a directory location of said redo log. It should be noted that 
obtaining directory information about the location of a redo log in a distributed system of redo 
logs as claimed is not trivial and is not taught or suggested by simply locating a log for the client. 

Applicant respectfully submits that Crowe teaches backup via broadcast to a plurality of 
nodes wherein each database partially overlaps at least one of the other databases (Abstract) but 
does not teach or suggest backing up data in a shared common database. Applicant respectfully 
submits that Crowe does not cure the deficiencies of Bamford, and nothing in Crowe or Bamford 
combined teaches or suggests "backing up database data files, control files and archived redo 
log in said shared common database by accessing data in said shared common database 
and also in said local archived redo log to provide backup data" as claimed in amended 
claim 7, or "obtaining information regarding a directory location of said redo log for said at 
least one node" as claimed. Since no combination of Bamford or Crowe teaches or suggests 
each element of independent claim 7 as amended, Applicant respectfully submits that the 
rejections under 35 U.S.C. § 103 are overcome. Reconsideration is respectfully requested. 
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CONCLUSION 



In view of the amendments and remarks set forth above. Applicant respectfully submits 
that the pending claims are patentably distinct and in condition for allowance. Authorization is 
hereby given to charge deposit account 50-2896 in connection with any fees or extension of time 
or any other fee that may be necessary to permit entry of this response. 

The Examiner is invited and encouraged to telephone the undersigned with any concerns 
or requests in furtherance of the prosecution of the present application. 



Respectfully submitted, 



Dated: May 13. 2009 /Brian L. Michaelis/ 

Brian L. Michaelis (Reg. No. 34,221) 

Attomey for Applicant(s) 

Seyfarth Shaw LLP 
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Boston, MA 02210-2028 
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